Traditional in-memory applications, such as in-memory databases and key-value stores, store data and metadata in volatile memory for fast access and persist the data/metadata to nonvolatile storage on a periodic basis to avoid data loss in the case of a system restart, crash, or failure. With this approach, the data/metadata structures (i.e., objects) maintained in volatile memory generally need to be serialized when persisting the data/metadata to nonvolatile storage and de-serialized when reconstructing the data/metadata in volatile memory during a system restart or crash recovery. These serialization and de-serialization processes can be time-consuming and compute intensive.
With the development of byte-addressable persistent memory technologies such as phase change memory (PCM), nonvolatile DIMMs (NVDIMMs), and the like, it is now possible for in-memory applications to both access and persist their data/metadata objects directly from/to such persistent memory. Due to the speed and nonvolatile nature of byte-addressable persistent memory, this approach enables in-memory applications to achieve throughput and latency performance that is similar to using volatile memory, while at the same time avoiding the need to write out their data/metadata to disk (thereby eliminating the serialization and de-serialization described above).
Typically, the process of using byte-addressable persistent memory as a direct object store for an in-memory application involves carving out a persistent heap in the byte-addressable persistent memory and mapping the persistent heap to a virtual address space of the application. This allows the application to read and write objects from/to the persistent heap using direct memory operations. However, in some cases, the computer system on which the application runs may randomize the base virtual memory address of the persistent heap after each system or application restart for, e.g., security purposes. In other cases, the application may be brought up on a different computer system that uses a different virtual memory layout. In these and other similar scenarios, any memory pointers included in the objects in the persistent heap will become invalid upon system restart/recovery because the persistent heap will be mapped to a different virtual address range. Accordingly, there is a need to identify all of these pointers and “swizzle,” or convert, the pointers based on the new memory mapping so that they can be correctly de-referenced at runtime.